Server-side gaming method and system for the delivery of remotely-rendered content comprising impression content

ABSTRACT

A server-side gaming method performed by a framework for delivering remotely-rendered content. The framework comprises a provisioning server for generating impression content, a remote server for generating frames of the remotely-rendered content comprising gaming content and the impression content; and an API for sending and receiving. The method comprises requesting from the provisioning server, a media asset associated with the impression content; and storing the media asset in storage of the remote server. On receipt of a request from the first user device, generating, a first instance of remotely-rendered content, where the impression content comprises the stored media asset. On receipt of a request from the second user device. generating a second, different, instance of remotely-rendered content, where the impression content comprises the stored media asset. Transmitting, to the first user device, the first instance and transmitting to the second user device, the second instance.

BACKGROUND OF THE INVENTION Field of the Invention

The present disclosure relates to server-side gaming methods and systemsrelating to the delivery of remotely-rendered content to user devices.The disclosure has particular, but not exclusive, relevance toremotely-rendered content comprising impression content.

Description of the Related Technology

The popularity of video games has risen meteorically, and currently theglobal video game industry is worth more than the music and filmindustries combined. In the early years of gaming, video game developersand associated entities made money through the sale of video games onphysical media (laserdiscs and cartridges). Nowadays, video games aremore often downloaded or even streamed onto a connected gaming devicesuch as a personal computer, games console or smartphone. Whilst thismodel still allows commercial entities to make money from the sale ofvideo games, it is common for further revenue streams to be pursuedbased on the sale of advertising space, including advertising spacewithin the video games themselves. In the context of video games,adverts may be presented to a user as part of a loading screen or menu,or alternatively may be rendered within a computer-generated environmentduring gameplay, leading to the notion of in-game advertising. Forexample, in a sports game, advertising boards within a stadium maypresent adverts for real-life products. In an adventure game orfirst-person shooting game, adverts for real-life products may appear onbillboards or other objects within the game environment.

Revenue models based on the sale of advertising space are ubiquitous inthe context of film and television, as well as for websites and socialmedia applications. Advertisers are typically charged in dependence onthe expected or actual reach of a given advert, or in other words theexpected or actual number of “impressions” of the advert experienced byconsumers hence the term impression content. For television and film, anadvertising fee may be negotiated in dependence on several showings ofthe advert and a predicted audience size for each showing. For a websiteor social media application, the advertising fee may be related toseveral page views or clicks. The distribution of an advert may then becontrolled in dependence on these factors.

In the above cases, it is technically straightforward to predict andmeasure the number of advertising impressions experienced by users. Forvideo games, the situation is different. Because different players willexperience a given video game differently depending on actions taken bythe players and/or random factors within the video game code, it is notgenerally possible to predict the extent to which a given advert withina video game will be viewed, and therefore the number of impressionsexperienced by the player. For the advertising revenue model to beapplied to in-game advertising, the visibility of an advert maytherefore be measured in real-time as a video game is played.

Tracking both the receipt of the advertisement at individual userdevices and monitoring whether the advertisement is viewed by the userduring gameplay is a complex and computationally expensive process.

SUMMARY

In accordance with a first aspect, there is provided a server-sidegaming method performed by a framework for delivering remotely-renderedcontent comprising impression content to at least a first user deviceand a second user device, the framework comprising: a provisioningserver arranged to generate and manage the impression content; a remoteserver arranged to generate a plurality of frames of theremotely-rendered content, wherein the plurality of frames ofremotely-rendered content comprises gaming content and the impressioncontent; and an application programming interface, API, for sending andreceiving data between the first and second user devices and the remoteserver. The method comprising requesting, by the remote server and fromthe provisioning server, at least one media asset associated with theimpression content; storing the at least one media asset associated withthe impression content in storage associated with the remote server; onreceipt of a request from the first user device to the remote serverusing the API, generating, at the remote server, a first instance ofremotely-rendered content, wherein the impression content of the firstinstance of remotely rendered gaming content comprises the at least onemedia asset stored in the storage associated with the remote server; onreceipt of a request from the second user device to the remote serverusing the API, generating at the remote server, a second, different,instance of remotely-rendered content, wherein the impression content ofthe second instance of remotely-rendered content comprises the at leastone media asset stored in the storage associated with the remote server;and transmitting, to the first user device, the first instance ofremotely-rendered content and transmitting to the second user device,the second instance of the remotely-rendered content.

This enables the provision of media assets associated with theimpression content, such as images, text, video, and audio, to theremote server such that when the remotely rendered gaming content isgenerated, the media assets are stored locally, thereby reducingbandwidth and processing at the provisioning server. As there is norequirement to request and download the media assets from theprovisioning server during the actual generation of the remotelyrendered content efficiency is increased since the same media assets canbe reused whilst generating content for multiple user devices andaccessed quicker since the connection between the storage associatedwith the remote server is faster than the connection between theprovisioning server and the remote server.

The request, sent by the remote server to the provisioning server, forat least one media asset associated with the impression content may bebased on an active period associated with the impression content. Thisallows the media asset to be prefetched based on when the impressioncontent will be active.

The active period associated with the impression content may be based ona time period during which the impression content is transmitted fromthe provisioning server to the remote server for generating theremotely-rendered content. This allows impression content to bedelivered during a given time period, and therefore assets associatedwith that impression content can be provided to the remote server inadvance.

Furthermore, the at least one media asset associated with the impressioncontent may be based on one or more predetermined filters. These filtersmay include characteristics of the first user device or second userdevice arranged to receive the remotely-rendered content; a ratingassociated with the remotely-rendered content; and an initialisationdate associated with the impression content. The characteristics of thefirst user device and second user device comprise at least an operatingsystem; hardware characteristics; an internet protocol or other uniqueidentifier; and a geographical location. This enables the provision ofthe media assets to the storage of the remote server to be limited basedon a number of filters such as age rating, platform, IP Address, andgeographical location. This ensures that only the relevant media assetsare downloaded to the remote server based on the remotely-renderedcontent that remote server is generating.

The at least one media asset associated with the impression content maybe based on similarity to impression content previously transmitted toat least one of the first user device or the second user device. Thisenables the provision of the media assets to the storage of the remoteserver to be based on their similarity to previous impression contentdelivery to the user device.

The framework may comprise a plurality of provisioning servers, andwherein the request for at least one media asset associated with theimpression content is sent by the remote server to at least one of theplurality of provisioning servers, wherein the at least one provisioningserver is selected based on a proximity of the at least one provisioningserver to the remote server. The proximity of the at least oneprovisioning server to the remote server is based on at least one of ageographical location of the at least one provisioning server; ageographical location of the remote server; and a response time of atransmission between the remote server and the at least one provisioningserver. This enables a provisioning server to be selected based on theproximity to the remote server. For example, if the remote server is ina given data center, then the provisioning server may be a provisioningserver from the same or adjacent data center, or another nearby datacenter. This ensures that the assets downloaded are obtained from nearbyprovisioning servers, thereby having a positive impact on the speed andlatency when downloading media assets for use in generating theremotely-rendered content at the remote server.

According to a second aspect, there is provided a system for deliveringremotely-rendered content comprising impression content to at least afirst user device and a second user device, the system comprising aprovisioning server arranged to generate and manage impression content;a remote server arranged to generate a plurality of frames ofremotely-rendered content, wherein the plurality of frames of remotelyrendered gaming content comprises gaming content and the impressioncontent; a first user device arranged to receive the remotely-renderedcontent; a second user device arranged to receive the remotely-renderedcontent; and an application programming interface, API, for sending andreceiving data between the first and second user devices and the remoteserver. The remote server comprises a request module for requesting, bythe remote server and from the provisioning server, at least one mediaasset associated with the impression content; storage for storing the atleast one media asset associated with the impression content in storageassociated with the remote server; a generation module for generating atleast: a first instance of remotely-rendered content, wherein theimpression content of the first instance of the remotely rendered gamingcontent comprises the at least one media asset stored in the storageassociated with the remote server on receipt of a request from the firstuser device to the remote server using the API; and a second, different,instance of remotely-rendered content, wherein the impression content ofthe second instance of the remotely-rendered content comprises the atleast one media asset stored in the storage associated with the remoteserver on receipt of a request from the second user device to the remoteserver using the API; and a transmission module for transmitting, to thefirst user device, the first instance of remotely-rendered content, andtransmitting, to the second user device, the second instance of theremotely-rendered content.

According to a third aspect, there is provided a non-transient storagemedium comprising computer-readable instructions which, when executed bya computing system, cause the computing system to perform the methoddescribed above.

Further features and advantages of the invention will become apparentfrom the following description of preferred embodiments of the inventiongiven by way of example only, which is made with reference to theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows, schematically, a user device for receiving gaming contentaccording to an example;

FIG. 2 shows a flowchart for a method of requesting impression contentaccording to an example;

FIG. 3 is a schematic representation of a system according to anexample;

FIG. 4 shows a flowchart for a method of confirming the receipt ofimpression content at a user device according to an example;

FIG. 5 is a schematic representation of a system for performing themethod of FIG. 4 ;

FIG. 6 shows a flowchart for a method of ensuring reliable event datadelivery to a provisioning server according to an example;

FIG. 7 is a schematic representation of a system for performing themethod of FIG. 6 ;

FIG. 8 shows a flowchart for a method of remote server caching accordingto an example; and

FIG. 9 is a schematic representation of a system for performing themethod of FIG. 8 .

DETAILED DESCRIPTION OF CERTAIN INVENTIVE EMBODIMENTS

Details of methods and systems according to examples will becomeapparent from the following description with reference to the figures.In this description, for the purposes of explanation, numerous specificdetails of certain examples are set forth. Reference in thespecification to ‘an example’ or similar language means that a feature,structure, or characteristic described in connection with the example isincluded in at least that one example but not necessarily in otherexamples. It should be further noted that certain examples are describedschematically with certain features omitted and/or necessarilysimplified for the ease of explanation and understanding of the conceptsunderlying the examples.

Embodiments of the present disclosure relate to monitoring and verifyingthe receipt of remotely-rendered content at a user device. Theremotely-rendered content comprises gaming content and impressioncontent, which is content, such as an advertisement, for which anadvertiser would be charged depending on the expected or actual reach ofa given advert in accordance with an advertising revenue model. In otherwords, the expected or actual number of “impressions” of the advertexperienced by users on their devices. The remotely-rendered content maybe rendered on a server, such as in a cloud computing environment, whereeach instance of the game (e.g., a game requested and accessed by a uservia their user device) is operating in its own isolated network segment,such as a virtual machine.

Cloud computing is a model for service delivery enabling on-demandnetwork access to shared resources including processing power, memory,storage, applications, virtual machines, and services, that can beinstantiated and released with minimal effort and/or interaction withthe provider of the service. Cloud computing environments enable quickand cost-effective expansion and contraction of such resources byenabling the provisioning of computing capabilities, such as server timeand network storage as needed. Cloud computing enables the serviceprovider's resources to be pooled and to serve multiple consumers bydynamically assigning and reassigning physical and virtual resources ondemand. Examples of such services include Amazon Web Services™ (AWS),Microsoft Azure, and Google Cloud Platform.

Services delivered using a cloud computing environment are oftenreferred to as Software as a Service (SaaS). The applications areaccessed from various user devices through a basic interface, such as aweb browser or other software program. A user of the applicationgenerally has no control or knowledge over where the provided resourcesare located or in some examples where multiple service providers areused, which service provider is providing the resources; access to theresources of the cloud computing environments is provided via a useraccount object which facilitates the user's interaction with theresources allocated to a given task within the cloud computingenvironment. Whilst a cloud computing environment is one of theconfigurations capable of generating/providing the remotely-renderedcontent, it will be appreciated that other environments may be used,such as a collection of servers within a local area network (LAN).

FIG. 1 shows, schematically, a user device 100 according to a firstexample. The user device 100 shown is a mobile telephone with a touchscreen interface, however, it will be appreciated that the user device100 may be a hand-held or laptop device, a desktop computer, amultiprocessor system, a microprocessor-based system, or a programmableconsumer electronic device comprising appropriate transmitting and/orreceiving capabilities. The user device 100 is arranged to receiveremotely-rendered content 110 for presentation to a user via a displayassociated with the user device 100. The remotely-rendered content 110is received from a remote server (not shown) which is responsible forgenerating the remotely-rendered content 110. The remotely-renderedcontent 110 comprises gaming content 110 a and impression content 110 breceived from a provisioning server (not shown). When generating theremotely-rendered content 110 the impression content 110 b and gamingcontent 110 a may be combined such that the impression content 110 bappears to be part of the gaming content 110 a, for example appearing onan advertising board shown in a three-dimensional environmentrepresented in the gaming content 110 a, which is tracked within thegaming content 110 a, as the user's playable character moves around thethree-dimensional environment. Further details regarding the interactionbetween the remote server, provisioning server, and user device will bedescribed below with reference to FIG. 2 .

The gaming content 110 a is content representing a game running on theremote server which is accessed by the user device 110. This gamingcontent 110 a can be generated in an isolated network segment running onthe remote server and operating in a cloud computing environment. Theimpression content 110 b may be an advertisement provided by athird-party advertising partner who has an advertising campaignconfigured to be presented with the game generated at the remote server.The advertising campaign may be configured to enable the impressioncontent 110 b to be presented in multiple different games and can betargeted to specific and/or groups of games based on several differentfactors. The management of the advertising campaign and other featuresof the impression content 110 b may be handled by the provisioningserver and transmitted to the remote server on request as will bedescribed with reference to FIG. 2 and FIG. 3 , below. Such features mayinclude an advertising revenue model associated with the impressioncontent.

In some examples, the user device 110 is also responsible for thetransmission of data back to the remote server indicating receipt of atleast the impression content 110 b, as well as other data such aswhether the impression content 110 b was viewed by the user on thedisplay of the user device 110.

To facilitate the transmission and/or receiving capabilities, the userdevice 110 may comprise a network adaptor that is arranged to facilitatecommunication with any number of remote resources, such as the remoteserver, via a network such as a local area network (LAN), a general widearea network (WAN), and/or a public network (e.g. the Internet). Thenetwork adaptor may be configured to communicate using either a wired orwireless communication method, such as cellular connectivity (LTE, 3G,4G, or 5G), ethernet, or over a Wi-Fi network. It will be appreciatedthat other types of user device 110 and transmitting and/or receivingcapabilities may be used.

FIG. 2 is a flowchart 200 showing a method for requesting impressioncontent and generating the remotely-rendered content for display on auser device, such as user device 100 described above with reference toFIG. 1 . Furthermore, FIG. 3 is an exemplary system 300 for implementingthe method described in FIG. 2 . A user of the user device 310 mayprovide an input to the user device 310 via a user interface thatlaunches an application or other software program, such as a web browserarranged to communicate with a remote server that is responsible forgenerating remotely-rendered content, such as a game. At step 210, theremote server starts a session with the user device 310, as indicated byarrow 310 s, which may retrieve information associated with the userdevice 310, including, but not limited to:

-   -   the operating system type and version of the user device;    -   the user device make and model;    -   details regarding the hardware components of the user device,        such as the processor type (e.g. 32-bit/64-bit); and    -   details regarding other software and applications installed on        the user device, such as antivirus software.

This information may be transmitted to the remote server 320 that isarranged to generate the remotely-rendered content via a networkconnection, as described above. Information may be provided to theremote server 320 via an application programming interface, API 330. TheAPI 330 is configured to facilitate the communication between the userdevice 310 and the remote server 320, such that information can bepassed from the user device 310 to the remote server 320 and vice versa.It is also determined whether the application/software program is toreceive remotely-rendered content via a cloud environment—such as oneoperating on the remote server 320. If so, the user device 310,communicates with the remote server 320 via the API 330.

At step 220, a request may be sent from the remote server 320 to aprovisioning server 340 as indicated by arrow 320 r. The provisioningserver 340 is responsible for the generation and management of theimpression content, such as advertisements, and campaigns associatedwith the impression content. As part of the request 320 r from theremote server 320, targeting information associated with the user device310, and the user of the user device 310 may be passed to theprovisioning server 340, to enable a suitable campaign to be selected.Such data may include:

-   -   the age of the user;    -   the gender of the user;    -   other personally identifiable information and/or        characteristics;    -   a unique user identifier;    -   a location of the user based on a location submitted or a        current location based on a global positioning system signal        received at the user device; and    -   user consent to data processing.

Once the request for the impression content has been received, at step230, an appropriate campaign can be selected. The campaign may comprisedifferent impression content, which is relevant based on the targetinginformation provided. For example, where location data is provided, thismay be utilized by the provisioning server 340 to select a suitablecampaign for that location, such that the user is shown impressioncontent suitable for their current location. This ensures the impressioncontent is more relevant.

In some examples, there may not be a relevant campaign to allocate, andin such a case a request may be sent to a third-party partner todetermine whether they would like to provide impression content based onthe targeting information associated with the user and user device 310.In other examples, there may be generic campaigns that are relevant tolarge groups of user and user devices, and where there are no availablecampaigns based on the targeting information, and no third-partypartners provide a suitable campaign based on the targeting information,the generic campaign may be selected.

Based on the allocated campaign, at step 240, impression content 110 bcan be selected and sent to the remote server 320 from the provisioningserver 340 as indicated by arrow 340 c. The impression content 110 bsent may comprise media assets such as image, video, text, hyperlinks,each being associated with the allocated campaign. In some examples, theprovisioning server 340 may modify media assets and/or selectpreconfigured media assets based on several characteristics, such as theuser device information, as described with reference to step 210, and/orother information such as the type of application/software programoperating in the cloud environment. It will be appreciated that userdevice information may be gathered at other times and used to modifyand/or select relevant media assets, for example when the user device isrotated the orientation of the user device will change and may becommunicated to the provisioning server 340 so as to enable theselection and/or modification of media assets. Such modifications mayinclude upscaling and downscaling the assets, adjusting padding at theedges of the assets, adjusting hyperlinks to relevant applicationprovisioning services based on the user device (e.g., the relevant AppStore on iOS® or Android™). In some examples, preconfigured mediaassets, such as representations of the media assets with differentresolutions may be stored at the provisioning server 340 and selectedbased on the user device information. In yet further examples, asdescribed below with reference to FIGS. 8 and 9 , the media assetsassociated with the impression content may have been prefetched andstored in storage associated with the remote server 320.

Upon receipt of the impression content 110 b at the remote server 320,the remote server generates the remotely-rendered content 110 whichcomprises the gaming content 110 a and the impression content 110 b, atstep 250. The combination of the game content 110 a and the impressioncontent 110 b can be dependent on several factors. For example, if thegame content 110 a is a simple two-dimensional fixed view game, then, asshown in FIG. 1 , there may be a fixed location for the impressioncontent 110 b. Alternatively, where the game content 110 a is a morecomplex three-dimensional game in which a user can explore athree-dimensional computer-generated environment, the impression content110 b may be associated with a given location and/or object within thethree-dimensional environment. Furthermore, there may be multiplelocations and/or objects within the gaming environment (whethertwo-dimensional or three-dimensional) associated with impression content110 b. In such examples, the impression content 110 b may differdepending on the location and/or associated object in the environment,and in some examples, different campaigns may be associated withdifferent locations and/or objects. In yet further examples, thelocation of the impression content 110 b within the gaming content 110 amay be determined dynamically, based on a given target within the gamingcontent 110 a, such as moving object, but also may be associated with auser's current location within a three-dimensional gaming environment,and/or by following a virtual camera within the three-dimensional gamingenvironment. In yet other examples, the location of the impressioncontent 110 b within the gaming content 110 a, can be randomized.

Once the remotely-rendered 110 content has been generated, at step 260,it is sent to the user device 310 for display, as indicated by arrow 320c. In certain environments, such as the three-dimensional gamingenvironments mentioned above, the user will view the remotely-renderedcontent 110 via a virtual camera within that environment. As such, therewill be instances where the impression content 110 b is not visible onthe viewable area of the display (e.g., it may be behind the virtualcamera) of the user device 310. Therefore, in some examples, the userdevice 310 may record viewability data associated with the impressioncontent 110 b (or each instance of the impression content). This datamay be sent back to the remote server 320 and/or provisioning server 340for analysis to refine and/or improve campaigns and impression content110 b locations. The remote server 320, API 330, and provisioning server340 collectively may be referred to as a framework 350.

Since the impression content 110 b is generated at the provisioningserver 340, and then combined with the gaming content at the remoteserver 320, the provisioning server 340 has no way of confirming whetherthe impression content 110 b was successfully received at the userdevice 310 and viewed by the user. Systems and methods for addressingthis will be described in further detail below with reference to FIGS.4-9 .

Confirming Receipt of Impression Content

A remote server, such as remote server 320, is responsible forgenerating the user consumable content, such as the plurality of framesof remotely-rendered content referred to above, where thisremotely-rendered content comprises at least one instance of theimpression content generated and managed by the provisioning server. Assuch, the remote server is configured to provide remotely-renderedcontent to at least one user device, and in some examples,simultaneously and in parallel to a plurality of user devices. Theremote server may operate in a cloud computing environment thatcomprises a plurality of isolated network segments, such as virtualmachines, which enables the remote server to handle a plurality ofrequests for different, or the same, remotely-rendered content. As willbe appreciated from the foregoing, the provisioning server, such as theprovisioning server 340, is responsible for generating and managing theimpression content, including recording the allocations of any benefitsto the authors of the impression content in accordance with anadvertising revenue model, such as when a user views an advertisementwithin a game. It can be useful for a provisioning server to confirmreceipt of the impression content at a user device (along with, in someexamples, confirming other information), for example to ensure thecorrect calculation and/or adjustment of the appropriate metrics.

A user device, such as user device 310, may request theremotely-rendered content from the remote server via an API, such as API330 described above. In some embodiments, the stability and quality ofthe network connection between the user device and the remote servercannot be guaranteed. As such, and as explained above, there is noguarantee that the impression content provided by the provisioningserver to the remote server will be received at the user device. FIG. 4shows a flowchart 400 of a method of confirming receipt of theimpression content at the user device 310 according to an example, andFIG. 5 shows a corresponding system 500.

As described above, the remote server 320 is responsible for generatinga plurality of frames of remotely-rendered content which are thentransmitted 320 c to the user device 310. Each frame ofremotely-rendered content may have a unique identifier, which can beindicated in the received frame information 540 sent by the user device310 to the remote server 320 on receipt of the request 550.

At step 410, received frame information 540 from a user device 310 isobtained using the API 330. The received frame information may bereceived via a network adapter associated with an input module 510 ofthe remote server 320. For example, the remote server 320, may send arequest 550 through the API 330, to the user device 310, to determinewhich frames of the remotely-rendered content have been received by theuser device 310. In some examples a separate request 550 may not berequired. For example, a bidirectional packet stream may be utilizedsuch that the user device periodically sends data to the remote server,and the remote server periodically sends frames of the remotely-renderedcontent 110 to the user device. It will be appreciated that othermethods of transmitting data, requests and frames of theremotely-rendered content 110 between the remote server 320 and userdevice 310; and for identifying which frames of remotely-renderedcontent have been received by the user device 310, may be used. Thisreceived frame information 540 may be stored in storage (not shown) ofthe user device 310, such that when a request 550 is received, thereceived frame information 540 transmitted to the remote server 320 mayrepresent the receipt of a plurality of frames of remotely-renderedcontent. The received frame information 540 may comprise the most recentidentifier which can then be used to indicate the receipt of a frame ofremotely-rendered content with said identifier.

As also described above, in some examples, the remotely-rendered contentis generated in an isolated network segment of a cloud computingenvironment, such as a virtual machine. In such examples, multiple userdevices may receive the remotely-rendered content, such as in amultiplayer game. As such, the received frame information 540 obtainedby the input module 510 at step 410 may be obtained from each of theuser devices that has received the remotely-rendered content.

Upon receipt of the received frame information 540 by the input module510 of the remote server 320, at step 420, it is determined whether thereceived frame information 540 comprises data relating to a new frame ofremotely-rendered content sent to the user device 310. Thisdetermination may be performed by a determination module 520 of theremote server. As described above, frames of remotely-rendered contentare transmitted 320 c to the user device 310 by the remote server 320,and information associated with that frame such as a unique identifieris retained at the remote server 320. Determining whether the receivedframe information 540 comprises data relating to a new frame ofremotely-rendered content that has been sent to the user device 310 maycomprise comparing the information regarding frames transmitted to theuser device 310 and the identifying information of the frames in thereceived frame information 540. The result of this comparison can beused to indicate whether any new frames of remotely-rendered contentcomprises new gaming content and new impression content that has beengenerated and transmitted since a previous check. If a new frame ofremotely-rendered content has been successfully received at the userdevice 310 the received frame information 540 sent from the user devicewill comprise an identifier associated with the new frame forremotely-rendered content.

Following the determination, at step 430 an indication 560 is sent tothe provisioning server. The indication 560 may be sent by atransmission module 530 of the remote server 320. This indication 560may be sent when it is determined that the received frame information540 comprises information associated with the new frame. Transmittingthe indication 560 to the provisioning server 340 ensures that theprovisioning server 340 is aware that the impression content 110 b hasbeen received by a user device 310. The indication 560 transmitted fromthe remote server 320 to the provisioning server 340 may compriseseveral different pieces of information, and in particular comprisesdata indicating that the new impression content, which forms part of thenew frame of remotely-rendered content, has been received at the userdevice 310.

In some examples, the indication 560 may comprise other information suchas performance data associated with the impression content. Theperformance data may comprise information such as user interaction withthe impression content, and be sent from the remote server 320 to theprovisioning server 340 to enable the provisioning server to adjustand/or alter the impression content based on user metrics and to improveor facilitate further user interaction. The performance data may beanalyzed by an analysis module 570 a of the provisioning server, whichis responsible for determining what, if any, alterations to make to theimpression content. Based on this analysis, a modification module 570 mof the provisioning server may modify and/or select the impressioncontent, which will then be transmitted to the remote server 320 for usewhen generating new frames of remotely-rendered content.

When the remotely-rendered content is transmitted to a plurality of userdevices, the indication 560 transmitted from the remote server 320 tothe provisioning server 340 may comprise at least data representative ofthe receipt of the new impression content at a first of the plurality ofuser device and a second of the plurality of user devices. That is, theindication may combine data associated with a plurality of user devicesand transmit this summarized data to the provisioning server 340. Thesummarized data may also comprise other data for one or more userdevices 310, such as viewability characteristics as described below.

The transmission of the indication 560 to the provisioning server 340may occur periodically, for example at predetermined time periods, or ata given time or times every day. In other examples, the transmission ofthe indication 560 may be based on factors associated with thetransmission 320 c of the remotely-rendered content to the user device310. One such example, as will be described in greater detail belowincludes transmitting the indication 560 from the remote server 320 tothe provisioning server 340 based on the quality of the connectionbetween the user device 310 and the remote server 320. Therefore, thequality of the connection between the user device 310 and the remoteserver 320 may be monitored over time, and periodically checked.

The quality of the connection, such as latency information between theuser device 310 and the remote server 320 may be determined, along withthe connection status of a connection between the user device 310 andthe remote server 320 to indicate whether to transmit the indication 560to the provisioning server 340. The connection status may be based on arecord of historical transmissions between the user device 310 and theremote server 320, which may be indicative of the quality of theconnection. For example, where the historical transmissions indicatethat the user device 310 regularly disconnects from the remote server320, the remote server 320 may send indications 560 to the provisioningserver 340 more regularly to ensure that all data is correctly forwardedto the provisioning server 340 for analysis. It will be appreciated thatother characteristics and/or factors associated with the connection maybe used when determining the quality of the connection.

Determining Whether a User Viewed Given Impression Content

As described above, the indication 560 sent from the remote server 320to the provisioning server 340 comprises at least data indicating thatthe new impression content in a new frame of remotely-rendered contentwas received by a user device 310. However, just because the impressioncontent was received by a user device 310 does not necessarily mean thatthe impression content was viewed by a user of that user device 310. Forexample, where the remotely-rendered content comprises three-dimensionalgaming content, the impression content may be inserted at a location inthat three-dimensional environment which is out of view of the user—thatis whilst it has been transmitted to the user device, if a view shown onthe display of the user device 310 does not show that location, then theuser will not have viewed the impression content. This is useful for thethird-party partners who provide the impression content, as theadvertising revenue model may need to ensure that any views of theimpression content are accurately recorded, not just the receipt of theimpression content at a user device 310.

As such, the indication 560 sent from the remote server 320 to theprovisioning server 340 may comprise additional data such as aviewability characteristic associated with at least one of the frames ofremotely-rendered content. In some examples, a separate indication maybe sent from the remote server to the provisioning server 340 comprisingonly the viewability information, this indication may be sentperiodically, at the same time or within the same time period as theindication 560 of receipt of the impression content. The viewabilitycharacteristic may be determined based on several different pieces ofviewability information and the connection between the user device 310and the remote server 320. This viewability information may be obtainedby the input module 510 of the remote server 320 as a separate datapackage received at substantially the same time as the received frameinformation 550, or as part of the received frame information 550itself. In some examples, the remote server 320 may handle receipt ofthe received frame information 550 and the viewability informationseparately. Determination of the viewability characteristic based on theviewability information may be undertaken by the determination module520, or an additional viewability determination module 520 v.

The viewability information may include the amount of time acrossnumerous frames of remotely-rendered content that the impression contentwas visible, and the size of a portion of the impression content whichwas visible on the display of the user device 310. In some examples, theviewability information may be combined with the user deviceinformation, such as to provide the size of the display of the userdevice 310. Where the remotely-rendered content comprisesthree-dimensional gaming content, impression content visible on thedisplay of the user device 310 may be determined based on a viewrepresentative of the perspective of a virtual camera positioned withinthe three-dimensional gaming content. In other examples, the quality ofthe transmission 320 c of the remotely-rendered content from the remoteserver 320 to the user device 310 can be considered when determining theviewability characteristic. For example, if the quality of thetransmission 320 c is poor, such that the bit rate of the transmissionbetween the remote server 320 and the user device 310 is below a giventhreshold, then the viewability characteristic can reflect that.

It will be appreciated that other viewability information may be usedwhen determining the viewability characteristic. Furthermore, whendetermining the viewability characteristic, determination module 520,520 v may combine the viewability information in accordance with apredetermined metric. This enables the determination of whether theimpression content was actually viewed to be dependent on theremotely-rendered content, and more particularly, the gaming content.For example, if the gaming content is a low-resolution 8-bit game thenthe bit-rate of the transmission between the remote server 320 and userdevice 310 is less important than say the size of a portion of theimpression content visible on the display of the user device 310.Similarly, if the gaming content is a high-resolution three-dimensionalgame, then the size of a portion of the impression content visible onthe display of the user device 310 may be more important to ensure thatthe impression content is positioned and displayed large enough withinthe three-dimensional environment for a user to be able to see it on thedisplay.

When combined, these different factors can be used to determine theviewability characteristic, and when compared to a predeterminedthreshold, if the viewability characteristic falls below that thresholdthen it may be determined that the impression content was notsuccessfully viewed by the user. For example, if the bit rate is so lowthat the impression content is pixelated or blurred on the display ofthe user device 310, then this may be considered as not being viewed bythe user.

Between the receipt of different frames of the remotely-rendered contentat the user device, the viewability information may change. For example,the viewing angle associated with a view from the perspective of avirtual camera within the three-dimensional gaming content may changebased on the movements of a user's playable character in the gamingcontent. This change in the viewability information may be stored at theremote server 320 and transmitted as part of the indication to theprovisioning server 340. One such example includes where a user isplaying a game on the user device and indicates that the playablecharacter is to move such that it is looking in the direction of theimpression content. In such a case the next frame of remotely-renderedcontent rendered by the remote server 320 will comprise the impressioncontent since the viewing angle of the virtual means that the impressioncontent is visible within the field of view of the playable character.The viewing information stored at the remote server 320 will thereforehave changed. This change may be stored and transmitted as part of theindication sent to the provisioning server 340. Similarly, at a latertime, the user may move the playable character such that they are nolonger viewing the impression content. In this case. the next frame ofremotely-rendered content will not comprise the impression content sincethe viewing angle of the virtual camera means that the impressioncontent is not visible within the field of view of the playablecharacter. Again, this change in the viewability information may bestored at the remote server 320 and transmitted as part of theindication sent to the provisioning server 340.

Reliable Event Data Delivery

As described above, the user device 310 may be a mobile device such as amobile telephone or laptop computing device and as such, the networkconnection between the user device and the remote server cannot beguaranteed, and/or maybe less reliable than the connection between theremote server 320 and provisioning server 340. This is because theremote server 320 and provisioning server 340 will often be connectedvia a wired network connection as opposed to a wireless connection, suchas cellular connectivity (LTE, 3G, 4G, or 5G), or a Wi-Fi network, usedby the user device 310 to communicate with the remote server 320.Furthermore, a user of a user device 310 is able to disconnect the userdevice 310 from the remote server 320, and/or stop the transmission ofevents to the remote server 320 with little to no notice, such as bypausing and/or quitting the game or other application, or disconnectingfrom the network connection.

It is desirable to capture event data associated with theremotely-rendered content, including but not limited to the receipt ofimpression content, viewability characteristics, and performance datadescribed above, in a timely and efficient manner. FIG. 6 shows aflowchart for a method 600 for reliable event data delivery to aprovisioning server 340 according to an example, and FIG. 7 shows acorresponding system 700.

At step 610, the characteristics of a connection 740 between a userdevice 310 and the remote server 320 are monitored. This may beundertaken by a monitoring module 710 of the remote server 320. Thecharacteristics of the connection 740 include at least a quality metricrepresentative of the transmission of the remotely-rendered content fromthe remote server 320 to the user device 310. The characteristics mayinclude the latency of the connection 740, bandwidth, and any otherrelevant metrics, which indicate the quality of a connection.

In some examples, the connection characteristics may be monitored over agiven time period and the quality of the transmission of data betweenthe remote server 320 and the user device 310 based upon the changes inthe characteristics over that given time period. This may be undertakenby the monitoring module 710, and or another module such as an analysismodule (not shown) of the remote server 320.

Based on the monitored connection characteristics, at step 620, it isdetermined whether the connection characteristics of the connection 740between the user device 310 and remote server 320, using the API 330,meet a predetermined threshold. For example, this can be used todetermine whether the connection quality of the connection 740 betweenthe user device 310 and the remote server 320 has degraded and/or isdegrading over a given time period. This may be undertaken by adetermination module 720 of the remote server 320. The predeterminedthreshold may be based on several factors and may be adjusted based onthe analysis of the connection characteristics monitored over a giventime period. The predetermined threshold may be based on a desiredconnection quality which is determined based on the monitored connectioncharacteristics, for example, a given bandwidth, and latency. It will beappreciated that other metrics may be used to specify the predeterminedthreshold.

When it is determined that the characteristics of the connection 740indicate a drop in the quality of the connection 740, the remote server320 transmits an indication 750 comprising at least the event dataassociated with the remotely-rendered content to the provisioning server340. As explained above, the event data may comprise indicationsrepresentative of the receipt of a frame of the remotely-renderedcontent, viewability characteristics, and performance data in accordancewith the examples previously described. This enables event data, andpreferably all event data associated with the remotely-rendered contenttransmitted to the user device 310, to be flushed from the remote server320 when the connection characteristics indicate a degradation in thequality of the connection between the user device 310 and remote server320. By flushing the event data 750, it is ensured that the provisioningserver 340 has the most up-to-date event data in the event of adisconnection between the user device 310 and the remote server 320,which would result in the subsequent disconnection between theprovisioning server 340 and an instance of a program of the remoteserver 320 (such as a game operating in a virtual machine of a cloudenvironment of the remote server 320) that was being accessed by theuser device This will also ensure resources at the remote server aremade available for other processing tasks.

In some examples, the remote server 320 may have associated storage 760for storing the event data associated with the remotely-rendered contentalongside other data, such as the received frame information describedabove with reference to FIGS. 4 and 5 . This event data may then becombined with the other data or other event data associated with otherremotely-rendered content comprising the same impression content, andtransmitted to the provisioning server 340 as part of the indication750. The storage 760 may be a solid-state drive (SSD) or othersemiconductor-based RAM; a magnetic recording medium, for example, afloppy disk or hard disk; optical memory devices in general, although itwill be appreciated that other storage mediums may be used. Whilst thestorage 760 is shown to be part of the remote server 320 itself, it willbe appreciated that the storage 760 may be storage that is remote to theremote server 320 and accessed by the remote server 320 over a networkconnection.

When the event data is stored in the storage 760 associated with theremote server 320, it is desirable to efficiently manage the use of thatstorage 760, not only for event data, but also other data required forthe remote server 320, such as for generating the remotely-renderedcontent, and/or storing other media assets. Therefore, following thetransmission of the indication 750 comprising the event data to theprovisioning server, the event data may be deleted from the storage 760.The efficient management of the storage 760 may be undertaken by astorage management module 760 m. The storage management module 760 m maybe arranged to delete the event data from the storage 760 immediately,or shortly after, the transmission of the indication 750 to theprovisioning server 340. In some examples, it may be desirable to ensurethe delivery of the indication 750 to the provisioning server 340 hasbeen successfully completed prior to deletion. In such examples, theprovisioning server 340 may send an acknowledgement/confirmation message780 to the remote server 320. The confirmation message 780 may bereceived by an input module 770. Upon receipt of the confirmationmessage 780 at the remote server 320, the storage management module 760m may delete the event data from the storage 760.

In addition to detecting whether the connection characteristics indicatethe quality of a connection 740 has degraded, in some examples, theindication 750 may be transmitted to the provisioning server 340 whenthe capacity of the storage 760 for the event data exceeds apredetermined capacity threshold. In such an example, the availablecapacity of the storage 760 associated with the remote server 320 may bemonitored by the storage management module 760 m, and the determinationmodule 720 may determine when the available capacity of the storage 760is below a given capacity threshold. When it is determined that thecapacity of the storage 760 is below the capacity threshold, theindication 750 may be transmitted to the provisioning server 320.Following the transmission of the indication 750 to the provisioningserver 320, the event data may be deleted from the storage 760. Asdescribed above, this may be undertaken immediately or shortly after thetransmission of the indication 750, or in some examples, the deletionmay occur upon receipt of an acknowledgement/confirmation message 780sent by the provisioning server 340 and received by the remote server320.

In some examples, determining whether the connection characteristicsmeet the predetermined threshold may comprise monitoring the frequencyof transmissions of the event data between the remote server 320 and theprovisioning server 340. This may also include calculating a time sincethe last transmission to the provisioning server 340 based on the timeof transmission of data most recently received from the user device 310.If the time between the last transmission to the provisioning server 340and the time of the last transmission received from the user device 310exceeds a predetermined time threshold, then this may be used toindicate that the indication 750 should be transmitted to theprovisioning server 340 as it may not be desirable to store largeamounts of event data at the remote server 320. In such an example, thepredetermined time threshold may be proportional to the capacity ofstorage 760 associated with the remote server 320, such that the smallerthe capacity of the storage 760, the shorter the predetermined timethreshold. This helps to maintain sufficient storage capacity 760 forfuture event data.

Remote Server Caching

As described above, the remote server 320 may operate a cloud computingenvironment that comprises a plurality of isolated network segments,such as virtual machines, which enables the remote server to handle aplurality of requests for different, or the same, in the case ofmultiplayer gaming content, instances of remotely-rendered content. Insome examples, the same impression content forming part of theremotely-rendered content may, therefore, be used in multiple instancesof the remotely-rendered content. In such examples, multiple requestsmay be made from the remote server 320 to the provisioning server 340requesting the same media assets, such as image data, video data, audiodata and/or text. Multiple requests sent from the remote server 320 tothe provisioning server 340 results in increased bandwidth requirementsand, once received by the remote server 320, storage of what isessentially the same media asset(s), more than once.

Accordingly, to improve resource usage relating to impression content,and the associated media assets, it is desirable to cache at least someof the media assets at the remote server 320. FIG. 8 shows a flowchartfor a method 800 remote server caching according to an example, and FIG.9 shows a corresponding system 900.

At step 810, the remote server 320 requests 950 at least one media assetassociated with the impression content, from the provisioning server340. The request 950 may be undertaken by a request module 910 of theremote server 320. The request 950 may be initialised because the remoteserver 320 is generating multiple instances of remotely-renderedcontent, each having the same impression content.

In some examples, the framework 350 described above with reference toFIG. 2 may comprise a plurality of provisioning servers 340, and therequest 950 from the remote server 320 may be sent to at least one ofthe provisioning servers 340 based on proximity of the provisioningserver 340 to the requesting remote server 320. The proximity may bebased on several different factors including the geographical locationof the remote server 320 and the provisioning servers 340 and/or aresponse time of a transmission between the remote server 320 and eachof the plurality of provisioning server 340. This enables provisioningservers 340 to be selected based on the proximity to the remote server320 such that any assets are downloaded to the remote server 320 moreefficiently, that is the provisioning server 340 that will provide themost timely response; and that such assets are geographically relevantto the user devices 310 a, 310 b requesting remotely-rendered contentfrom the remote server 320.

At step 820, the media asset 960 associated with the impression contentis received by the remote server 320 and is stored in storage 920. Thestorage 920 may be a solid-state drive (SSD) or othersemiconductor-based RAM; a magnetic recording medium, for example, afloppy disk or hard disk; optical memory devices in general, although itwill be appreciated that other storage mediums may be used. Whilst thestorage 920 is shown to be part of the remote server 320 itself, it willbe appreciated that the storage 920 may be storage that is remote to theremote server 320 and accessed by the remote server 320 over a networkconnection. The connection between the remote server 320 and the storage920 may be faster than the connection between the provisioning server340 and the remote server 320, which will result in faster access to themedia assets 960 stored thereon.

In some examples, selection of the at least one media asset 960 by theprovisioning server 340 may be based on one or more factors. Thesefactors may include information associated with a given campaign, and/ordata provided by the user devices 310 a, 310 b to the remote server 320which may make up part of the request 950. For example, a particularcampaign may have a given active period during which it is to be shown,and therefore any requests for media assets during that active periodmay be based on that active period. Other factors may include thelocation of a given user device 310 a, 310 b.

Similarly, the one or more media assets 960 provided by the provisioningserver 340 may be based on one or more predetermined filters. Thesefilters may include characteristics of the first 310 a and/or second 310b user devices arranged to receive the remotely-rendered content. Thesecharacteristics may have been provided by the respective user device 310a, 310 b as described above with reference to FIG. 2 , and may includethe operating system of the user device 310 a, 310 b, hardwarecharacteristics of the user device 310 a, 310 b such as processor typeand/or capabilities, a unique identifier associated with the user device310 a, 310 b which may include an internet protocol address, and ageographic location obtained from the user device 310 a, 310 b.

In addition to characteristics associated with the user device 310 a,310 b, the filters may comprise other characteristics such as a ratingassociated with the remotely-rendered content, and a date and/or timeassociated with the initialisation of the impression content, such as anadvertising campaign start date. These predetermined filters enablemedia assets 960 to be requested and/or provided by the provisioningserver 340 to be tailored and customized. For example, the media assets960 may be age-restricted based on the remotely-rendered content, thatis it would be inappropriate to provide certain media assets forinclusion in remotely-rendered content which comprises gaming contentfor a children's game. Similarly, the filters enable the media assets960 to be tailored based on the location of a user device 310 a, 310 barranged to receive the remotely-rendered content. For example, it maybe inefficient to cache a media asset in Chinese to a remote server 320which only serves user devices 310 a, 310 b located within the UnitedStates.

In other examples, the media asset 960 associated with the impressioncontent for use in the generation of the remotely-rendered content maybe based on impression content previously transmitted from the remoteserver 320 to at least one of the first user device 310 a or second userdevice 310 b. This enables the provisioning of media assets to be basedon the previous impression content delivered to the user devices,thereby enabling similarity and/or continuity between the impressioncontent. One such example, where the impression content is anadvertisement, where a media asset associated with a particular brandhas been used in impression content provided to a given user device,future impression content may also include media assets associated withthat particular brand.

Returning to method 800, upon receipt and storage of the media asset 960associated with the impression content, at step 830, a request 970 a isreceived from a first user device 310 a to the remote server 320 for afirst instance 980 a of the remotely-rendered content generated by theremote server 320. The first instance 980 a of the remotely-renderedcontent comprises impression content generated by the provisioningserver 340, whereby the impression content comprises the media asset 960stored in the storage 920 of the remote server 320. The first instance980 a of the remotely-rendered content is generated at the remote server320 by a generation module 930.

Similarly, at step 840, a request 970 b is received from a second userdevice 310 b to the remote server 320 for a second, different, instance980 b of the remotely-rendered content generated by the remote server320. The second instance 980 b of the remotely-rendered content alsocomprises the same impression content generated by the provisioningserver 340, and as such, the impression content comprises the mediaasset 960 stored in the storage 920 of the remote server 320. The secondinstance 980 b of the remotely-rendered content may also be generated atthe remote server 320 by a generation module 930.

Since both the first instance 980 a of the remotely-rendered content andthe second instance 980 b of the remotely-rendered content comprise thesame impression content which in turn comprises the same media assets960 stored in the storage 920 of the remote server 320, efficiencies canbe gained as multiple requests for the same media asset 960 are nolonger required. The impression content can be generated using the mediaasset 960 stored in the storage 920 when the remote server 320 generatesthe instances 980 a, 980 b of the remotely-rendered content.

Following the generation of the first instance 980 a and second instance980 b of the remotely-rendered content, at step 850, the first instance980 a and second instance 980 b are transmitted to the first user device310 a and second user device 310 b respectively. This transmission maybe undertaken by a transmission module 940 associated with the remoteserver. As with other examples described above, the first instance 980 aand the second instance 980 b may be transmitted using an API 330 whichis configured to handle communication between the remote server 320 andthe user devices 310 a, 310 b. Whilst the steps 810, 820, 830, 840, 850have been described as sequential, it will be appreciated that at leastsome of the steps 810, 820, 830, 840, 850 may be undertaken in paralleland in any order. For example, steps 830 and 840, where the firstinstance 980 a and second instance 980 b of remotely-rendered contentare generated, these may be generated in parallel, rather thansequentially as described above.

At least some aspects of the embodiments described herein with referenceto FIGS. 1-9 comprise computer processes performed in processing systemsor processors. However, in some examples, the disclosure also extends tocomputer programs, particularly computer programs on or in an apparatus,adapted for putting the disclosure into practice. The program may be inthe form of non-transitory source code, object code, a code intermediatesource and object code such as in partially compiled form, or in anyother non-transitory form suitable for use in the implementation ofprocesses according to the disclosure. The apparatus may be any entityor device capable of carrying the program. For example, the apparatusmay comprise a storage medium, such as a solid-state drive (SSD) orother semiconductor-based RAM; a ROM, for example, a CD ROM or asemiconductor ROM; a magnetic recording medium, for example, a floppydisk or hard disk; optical memory devices in general; etc.

It is to be understood that although the disclosure above relates to theuse of cloud computing, the implementation described is not limited to acloud computing environment. Rather, embodiments of the presentdisclosure are capable of being implemented in conjunction with anyother type of computing environment.

In the preceding description, for purposes of explanation, numerousspecific details of certain examples are set forth. Reference in thespecification to “an example” or similar language means that aparticular feature, structure, or characteristic described in connectionwith the example is included in at least that one example, but notnecessarily in other examples.

The above embodiments are to be understood as illustrative examples ofthe disclosure. Further embodiments of the disclosure are envisaged. Itis to be understood that any feature described in relation to any oneembodiment may be used alone, or in combination with other featuresdescribed, and may also be used in combination with one or more featuresof any other of the embodiments, or any combination of any other of theembodiments. Furthermore, equivalents and modifications not describedabove may also be employed without departing from the scope of thedisclosure, which is defined in the accompanying claims.

What is claimed is:
 1. A server-side gaming method performed by aframework for delivering remotely-rendered content comprising impressioncontent to at least a first user device and a second user device, theframework comprising: a provisioning server arranged to generate andmanage the impression content; a remote server arranged to generate aplurality of frames of the remotely-rendered content, wherein theplurality of frames of remotely-rendered content comprises gamingcontent and the impression content; and an application programminginterface, API, for sending and receiving data between the first userdevice and the remote server, and the second user device and remoteserver, the method comprising: requesting, by the remote server and fromthe provisioning server, at least one media asset associated with theimpression content; storing the at least one media asset associated withthe impression content in storage associated with the remote server; onreceipt of a request from the first user device to the remote serverusing the API, generating, at the remote server, a first instance ofremotely-rendered content, wherein the impression content of the firstinstance of remotely rendered content comprises the at least one mediaasset stored in the storage associated with the remote server; onreceipt of a request from the second user device to the remote serverusing the API, generating at the remote server, a second, different,instance of remotely-rendered content, wherein the impression content ofthe second instance of remotely-rendered content comprises the at leastone media asset stored in the storage associated with the remote server;and transmitting, to the first user device, the first instance ofremotely-rendered content and transmitting to the second user device,the second instance of the remotely-rendered content.
 2. The server-sidegaming method according to claim 1, wherein the request, sent by theremote server to the provisioning server, for at least one media assetassociated with the impression content is based on an active periodassociated with the impression content.
 3. The server-side gaming methodaccording to claim 2, wherein the active period associated with theimpression content is based on a time period during which the impressioncontent is transmitted from the provisioning server to the remote serverfor generating the remotely-rendered content.
 4. The server-side gamingmethod according to claim 1, wherein the at least one media assetassociated with the impression content is based on one or morepredetermined filters.
 5. The server-side gaming method according toclaim 4, wherein the one or more predetermined filters are based on atleast one of: characteristics of the first user device or second userdevice arranged to receive the remotely-rendered content; a ratingassociated with the remotely-rendered content; and an initialisationdate associated with the impression content.
 6. The server-side gamingmethod according to claim 5, wherein the characteristics of the firstuser device and second user device comprise at least: an operatingsystem; hardware characteristics; an internet-protocol or other uniqueidentifier; and a geographical location.
 7. The server-side gamingmethod according to claim 1, wherein the at least one media assetassociated with the impression content is based on a similarity toimpression content previously transmitted to at least one of the firstuser device or second user device.
 8. The server-side gaming methodaccording to claim 1, wherein the framework comprises a plurality ofprovisioning servers, and wherein the request for at least one mediaasset associated with the impression content is sent by the remoteserver to at least one of the plurality of provisioning servers, whereinthe at least one provisioning server is selected based on a proximity ofthe at least one provisioning server to the remote server.
 9. Theserver-side gaming method according to claim 8, wherein the proximity ofthe at least one provisioning server to the remote server is based on atleast one of: a geographical location of the at least one provisioningserver; a geographical location of the remote server; and a responsetime of a transmission between the remote server and the at least oneprovisioning server.
 10. The server-side gaming method according toclaim 1, wherein the remotely-rendered content is generated in anisolated network segment associated with the remote server.
 11. A systemfor delivering remotely-rendered content comprising impression contentto at least a first user device and a second user device, the systemcomprising: a provisioning server arranged to generate and manageimpression content; a remote server arranged to generate a plurality offrames of remotely-rendered content, wherein the plurality of frames ofremotely rendered gaming content comprises gaming content and theimpression content; a first user device arranged to receive theremotely-rendered content; a second user device arranged to receive theremotely-rendered content; and an application programming interface,API, for sending and receiving data between the first and second userdevices and the remote server, wherein the remote server comprises: arequest module for requesting, by the remote server and from theprovisioning server, at least one media asset associated with theimpression content; storage for storing the at least one media assetassociated with the impression content in storage associated with theremote server; a generation module for generating at least: a firstinstance of remotely-rendered content, wherein the impression content ofthe first instance of the remotely rendered gaming content comprises theat least one media asset stored in the storage associated with theremote server on receipt of a request from the first user device to theremote server using the API; and a second, different, instance ofremotely-rendered content, wherein the impression content of the secondinstance of the remotely-rendered content comprises the at least onemedia asset stored in the storage associated with the remote server onreceipt of a request from the second user device to the remote serverusing the API; and a transmission module for transmitting, to the firstuser device, the first instance of remotely-rendered content, andtransmitting, to the second user device, the second instance of theremotely-rendered content.
 12. The system for deliveringremotely-rendered content according to claim 11, wherein the systemcomprises a plurality of provisioning servers, and wherein the request,by the remote server, is sent to at least one of the plurality ofprovisioning servers, the at least one provisioning server beingselected based on a proximity of the at least one provisioning server tothe remote server.
 13. A non-transitory computer-readable storage mediumcomprising a set of computer-readable instructions stored thereon which,when executed by at least one processor are arranged to deliverremotely-rendered content comprising impression content to at least afirst user device and second user device using a framework, theframework comprising: a provisioning server arranged to generate andmanage the impression content; a remote server arranged to generate aplurality of frames of the remotely-rendered content, wherein theplurality of frames of remotely-rendered content comprises gamingcontent and the impression content; and an application programminginterface, API, for sending and receiving data between the first userdevice and the remote server, and the second user device and remoteserver, wherein the instructions, when executed, cause the processor to:request, by the remote server and from the provisioning server, at leastone media asset associated with the impression content; store the atleast one media asset associated with the impression content in storageassociated with the remote server; generate, at the remote server and onreceipt of a request from the first user device to the remote serverusing the API, a first instance of remotely-rendered content, whereinthe impression content of the first instance of remotely renderedcontent comprises the at least one media asset stored in the storageassociated with the remote server; generate, at the remote server and onreceipt of a request from the second user device to the remote serverusing the API, a second, different, instance of remotely-renderedcontent, wherein the impression content of the second instance ofremotely rendered content comprises the at least one media asset storedin the storage associated with the remote server; and transmit, to thefirst user device, the first instance of remotely-rendered content, andtransmit, to the second user device, the second instance ofremotely-rendered content.